Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating DMOD Install Process and Docs #456

Merged

Conversation

robertbartel
Copy link
Contributor

  • Updating the INSTALL.md file and other documentation related to setting up DMOD
  • Updating scripts and config file templates to reduce the (required) manual steps to get DMOD up and running
  • Adding new helper scripts, template files, and template file content in service of the above
  • A few miscellaneous fixes to issues within the setup process (e.g., Cython version for t-route in ngen image build)

@robertbartel robertbartel added bug Something isn't working documentation Improvements or additions to documentation enhancement New feature or request maas MaaS Workstream labels Oct 31, 2023
| Dependency | Constraints | Notes |
|-------------------------------------------|:--------------------------------------------|:----------------------------------------------------------------------:|
| [Usage Dependencies](#usage-dependencies) | Same as above | |
| Python | \>=3.8.x | |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might want to bump that up to 3.9.x - we've got 3.9 somewhere in the pipeline (don't remember where). It's probably the github action.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The (perhaps unofficial) rule of thumb has been for DMOD to support all the versions of Python that are currently, officially supported, which includes 3.8 for now. Given ecosystems like RHEL's that aren't as quick to move to new versions, I think this could make a difference in community adoption (which this particular PR is also geared toward).

I could have sworn we had a matrix in the Github Actions to support testing on a handful of different Python versions, including 3.8 and 3.9. Maybe I'm mixing that up with somewhere else and we should add it here.

Regardless, if there is something specific for which we need to consider breaking with the current approach, then let's open a separate issue and formally consider it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could have sworn we had a matrix in the Github Actions to support testing on a handful of different Python versions, including 3.8 and 3.9. Maybe I'm mixing that up with somewhere else and we should add it here.

Ah, looks like I was remembering what Nels had set up in the ngen-cal project. We probably should adopt something similar.

@christophertubbs
Copy link
Contributor

Is this supposed to have all the DMOD client work?

@christophertubbs
Copy link
Contributor

All looks solid - I'll approve if it turns out that the client code wasn't an accidental branch leak.

@robertbartel
Copy link
Contributor Author

@christophertubbs , hmm, yeah that's probably a leak. Let me figure out what I just did.

Update example.env for correct wrf_hydro and troute branches.
Adding commented out examples for absent items and commenting out
examples for items that need to be handled with defaults.
Picking subnets for configured Docker networks that are less likely to
be encountered in the real world
Adding flag and option to helper script to init all standard service
self-signed SSL certs for a deployment.
Documenting several additional required dependencies:
- MinIO CLI client
- Pip
- Python dev headers/libs
- A C++ compiler
- docker_pre_deploy_bind_mount_dir_check
- docker_pre_deploy_create_secrets
- docker_pre_deploy_scheduler_resources
Temporarily deactivate subset service until things can be address (and
it is clear that it is necessary).
Updating script to automatically create necessary SSH keys built
into job worker images.
Update control_stack.sh to use single node if deploying when there is
only one available in the Docker Swarm.
Updating to support a couple different default command names,
accept a specified command name for minio client, avoid DNS
issues with 'localhost' and avoid SSL issues.
Add script to simplify creating scheduler resource config.
Automating pre-deploy checks/gen of Docker secret files, configured
bind mount directories, and scheduler configuration files.
@robertbartel
Copy link
Contributor Author

@christophertubbs, good catch. Thanks for that. I'm not exactly sure how I did that, but I've removed the superfluous commits now.

@christophertubbs
Copy link
Contributor

If I had a nickel for every time I had a branch leak I'd have enough money for a pack of post-its to remind me not to cause a branch leak.

Copy link
Contributor

@christophertubbs christophertubbs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything looks great

@christophertubbs christophertubbs merged commit 776a28c into NOAA-OWP:master Oct 31, 2023
1 check failed
@robertbartel robertbartel deleted the f/update_install_docs/main branch October 31, 2023 20:08
### Different Python Executable Names
It is quite common for the Python executables to be named `python3`, `python311`, `pip3`, etc. in the *global* Python environment, instead of just `python` and `pip`. This is accounted for when [creating a virtual environment](#using-a-virtual-environment), provided the right Python command was used to create it. Users not doing this should consider setting up shell aliases, symlinks in their path, or some other mechanism to ensure `python` and `pip` execute the desired versions appropriately.

> [!NOTE]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Neat! I didnt know about these markdown directives.


ngen:
version:
1: '127.0.0.1:5000/ngen:latest'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is probably worth tracking that both ngen and nwm image names these are hard coded in service.py at the moment. Im sure we will refactor this in the future to be more flexible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working documentation Improvements or additions to documentation enhancement New feature or request maas MaaS Workstream
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants